Agent 执行沙箱
Agent 要执行模型生成的代码、运行不可信的工具。执行沙箱决定了这些代码能碰到什么、碰不到什么，以及出问题时的爆炸半径。
本专题只讲生产运行时的隔离。 训练时也需要沙箱，但那是另一套东西 —— 并发规模差两个数量级、单个环境只活几十秒、而且必须能重置回同一个起点。那部分在 Agent 训练环境 专题，两者的逐条对比见 训练环境 01 篇。
先约定几个词，本专题全程使用：
| 词 | 意思 |
|---|---|
| 沙箱（sandbox） | 一个受限的执行环境，里面的代码伤不到外面。注意它限制的是「破坏能力」，不是「信息搬运能力」 |
| 逃逸（escape） | 沙箱里的代码突破隔离、拿到宿主机权限。这是所有隔离方案最终要防的那件事 |
| 宿主（host） | 跑着沙箱的那台机器或那个进程。相对地，沙箱内部叫 guest |
| 内核 | 操作系统的核心，负责管硬件和进程。沙箱和宿主共不共享内核，是三条路线最根本的分界 |
| 系统调用（syscall） | 程序请求内核干活的接口，比如打开文件、发网络包。拦不拦系统调用、在哪一层拦，决定了隔离强度和开销 |
| microVM | 精简过的虚拟机，去掉了传统虚拟机里绝大多数不必要的设备模拟，所以能在一百多毫秒内启动，代表实现是 Firecracker |
| 爆炸半径 | 出事之后影响到的范围。沙箱的意义就是把它从「整台宿主机」压缩到「一个沙箱实例」 |
一、这一层要回答的问题
模型生成了一段 rm -rf /，或者一个 MCP 工具在后台读你的 ~/.ssh/id_rsa —— 这两件事在没有隔离的环境里都会真的发生。
隔离要同时满足两个互相拉扯的要求：
隔离越强，启动越慢、资源开销越大。三条主流技术路线就是在这条轴上的三个不同位置。
二、三条隔离路线
← 快、弱隔离 慢、强隔离 →
三者不是简单的优劣关系 —— 02 篇会说明它们各自防住了什么、防不住什么。
三、正文构成
| # | 标题 | 覆盖内容 |
|---|---|---|
| 01 | 为什么需要沙箱 | 威胁场景、隔离的四个维度、什么时候不需要 |
| 02 | 三条隔离路线 | 容器 / microVM / 用户态内核的机制与边界 |
| 03 | E2B 与快照机制 | 冷启动为什么能做到百毫秒级、暂停恢复怎么实现 |
| 04 | 开源产品怎么做 | OpenHands 的五种 workspace 后端、Suna 的沙箱服务 |
| 05 | 选型与落地 | 判据、无沙箱路线的权限模型、与其他专题的接口 |
四、拆解对象
| 项目 | ★ | 协议 | 语言 | 定位 |
|---|---|---|---|---|
daytonaio/daytona | 71,960 | — | — | Agent 运行环境，star 最高 |
firecracker-microvm/firecracker | 36,147 | Apache-2.0 | Rust | microVM，AWS Lambda 与 Fargate 的底座 |
kortix-ai/suna | 20,119 | NOASSERTION | TypeScript | 最接近 Manus 的开源实现 |
google/gvisor | 19,118 | Apache-2.0 | Go | 用户态内核 |
e2b-dev/E2B | 13,474 | Apache-2.0 | Python | Agent 沙箱的事实标准 SDK |
superradcompany/microsandbox | 7,767 | Apache-2.0 | Rust | 轻量 microVM 方案 |
e2b-dev/infra | 1,331 | Apache-2.0 | Go | E2B 的服务端，快照机制在这里 |
OpenHands/software-agent-sdk | 1,008 | MIT | Python | 五种 workspace 后端并存 |
五、与其他专题的关系
- Agent 安全：沙箱是纵深防御的最后一道，安全 04 篇已指出它管不了数据外泄
- Agent 网关 · MCP 网关：工具级授权在网关侧，代码执行隔离在沙箱侧，两者互补
- Agent 持久化执行：沙箱的暂停恢复与工作流的检查点是同一类问题的不同层次
- Lobster0 项目沉淀：无沙箱、靠权限分层的实践对照
← 回到 Agent Infra 板块总览